@jrhouston When i do a go generate, it does not generate any resources

Tried to generate some Kubernetes resurces, but the resulting code does not work.
Consider a generic Kubernetes resource, that includes a spec and a status. Use the generator to generate the schema and the model for such a resource.

The model includes a struct representing the status. When creating an instance of a kubernetes resource, usually the status is not include in its specification (it is optional and computed). So Terraform attempts to set it as unknown.
Because the status is a struct, the terraform provider framework logic is unable to set the unknown status and the provider fails. A custom type would be required.

Also the manifest tags associated to each field in the generated structures have case issues. If the kubernetes resource contains an attribute named MyDHCP, the manifest entry is set to MyDhcp, thus creating a mismatch during the marshal and unmarshal processes.

The terraform openapi generator generates the correct structures, with types and values for every SingleNestedAttribute. But it is unable to add the manifest attribute that allows to map the openapi specification of the kuberntes resource to the generated model.

@jrhouston is there any plan to improve this pull request to have the generator generate better code? Mapping from kubernetes client structure to the terraform models generated by the openapi generator is really tedious

Thanks for pulling down the branch and trying this out @randomswdev. This is very much a draft where my goal was to generate a simple resource like ConfigMap. Using this for large resources with spec and status certainly won't work yet – I have a long todo list of things to fix to make this work.

The model includes a struct representing the status. When creating an instance of a kubernetes resource, usually the status is not include in its specification (it is optional and computed). So Terraform attempts to set it as unknown.
Because the status is a struct, the terraform provider framework logic is unable to set the unknown status and the provider fails. A custom type would be required.

Yep, a mechanism for supporting custom types is on my todo list.

Also the manifest tags associated to each field in the generated structures have case issues. If the kubernetes resource contains an attribute named MyDHCP, the manifest entry is set to MyDhcp, thus creating a mismatch during the marshal and unmarshal processes.

Yeah, this is annoying. I suspect we're going to add a mechanism in the openapi generator tool to give us the OpenAPI context for the attribute so we can access the field name. If we can't do that then likely we'll need a way of configuring a known list of acronyms so cases such as your DHCP example don't get mangled.

@jrhouston is there any plan to improve this pull request to have the generator generate better code?

Yup, the plan here is to make this generator work more generally and use it to migrate all the existing SDKv2 code to the plugin framework. After this we will look at breaking it out into it's own module that can be used to generate custom providers for Kubernetes.

Mapping from kubernetes client structure to the terraform models generated by the openapi generator is really tedious

Just out of interest, is there a specific use case you are dealing with that motivated you to try this PR?

Just out of interest, is there a specific use case you are dealing with that motivated you to try this PR?

We want to automate some k8s operations that include activities on custom resources. So we need terraform providers to interact with those CRDs.

We are looking for a fast and cheap way to develop these providers, and your generator appeared to be a quite easy solution.

Currently we opted for leveraging the OpenAPI generator with hand written code for mapping the generated models back and forth to the k8s API client structures.

If the future direction will be to extend the OpenAPI generator and the terraform plugin framework code generator to propagate "manifest" tags to the generated models, we will be able to automate also the mapping. And the need for custom code would be limited to very specific scenarios.